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PRE-APPEAL BRIEF REQUEST FOR REVIEW ARGUMENTS 



Applicants request a pre-appeal brief review of the rejection of the claims as anticipated 
(§ 102(e)) by US Pat. No. 6,754,773 to Ulrich. (hereinafter the "Ulrich reference") in the Final 
Office Action dated January 19, 2007 ("Final Office Action"). 

Claim 1, for example, is directed to a "data management method, comprising: receiving 
multiple user files from at least one client station coupled to a data storage subsystem; storing at 
least some of the multiple user files in a retrieval storage pool at a first location in the data 
storage subsystem; creating a managed file comprising an aggregation of at least some of the 
multiple user files; applying first predetermined criteria to a user file stored in the retrieval 
storage pool to designate the user file in the retrieval storage pool as one of a higher priority and 
a lower priority; and deleting from said retrieval storage pool a user file designated as lower 
priority." It is the Examiner's position that the recited "creating a managed file comprising an 
aggregation of at least some of the user files" is met by creation of a "Refresh Node" of the 
Ulrich reference cited by the Examiner. The applicants respectfiiUy disagree. 

The Ulrich reference makes clear that a "Refresh Node" of the Examiner's citation is 
merely a set of fields (Ulrich, col. 33, lines 1 et scq.). The fields of the Refresh Node are not 
"user files" which are received "from at least one client station coupled to a data storage 
subsystem" as required by claim 1 . Instead, the Refresh node fields are fields of data created 
for each client that registers a "lock or share." (Ulrich, col. 32, lines 58 et seq.) The Examiner 
has cited no portion of the Ulrich reference which indicates that a Refresh node field was utilized 
as a user file at a client station. Thus, it is clear that the fields of the Refresh Node cannot be 
considered to be an "aggregation of at least of some of the user files" which are received "from 
at least one client station coupled to a data storage subsystem" as required by claim 1 . 

The Examiner has also cited claim 27 of the Ulrich reference which recites "a distributed 
file system that aggregates files across a plurality of servers ... ." However, the Ulrich reference 
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makes clear the distributed files system cited by the Examiner "allows the integration of multiple 
servers so that the aggregation of servers appears to a cUent as a single storage device." Ulrich, 
col. 11, lines 53 et seq. It is respectfully submitted that servers aggregated to appear as a single 
storage device (storing individual files), are clearly not a "managed file" as that term is used in 
the present specification. The Examiner has cited no portion of the Ulrich reference which in 
any manner teaches or suggests "creating a managed file comprising an aggregation of at least 
some of the multiple user files" which are received "from at least one client station coupled to a 
data storage subsystem" as required by claim 1. 

The Examiner has also cited a "G-group" which is described in the Ulrich reference as a 
"set of contiguous Gees 2538 that all relate to a single file." However, the Ulrich reference 
makes clear that the Gees 2538 are a plurality of indexed rows containing fields 2532, 2534, 
2536 containing information relating to a single file 2605 (Ulrich reference, col. 55, lines 65 et 
seq., FIG. 29). Thus, it is clear that the fields of the Gees 2538 cannot be considered to be an 
"aggregation of at least of some of the user files" which are received "from at least one client 
station coupled to a data storage subsystem" as required by claim 1. 

It is the Examiner's position that the recited "creating a managed file comprising an 
aggregation of at least some of the user files" is met by the description in the Ulrich reference of 
the server creating a new file and allocating a new G-node for the new file, citing columns 41 
and 42, lines 63-67 and lines 1-42 of the Ulrich reference. The applicants respectfully disagree. 

The Ulrich reference makes clear that the new file created by the server is not an 
aggregation of user files but is instead a single user file created at the request of a client: 

"The process 1800 begins in a start state 1805 and moves to a state 1810 where the client 1 10 
send a file allocation request that includes a filename for a new file and a file handle for the new 
file's parent directory. 

The process 1800 moves to the state 1815, and the server node 150 indicated in the parent 
directory's file handle receives the file allocation request." Ulrich, col. 41, lines 49-55 

Thus, the file creation cited by the Examiner in the Ulrich reference clearly cannot be said to be 
"creating a managed file comprising an aggregation of at least some of the user files" as 
required by claim 1 . 
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The Examiner interprets the server's allocation of a "G-node" for the new file as the 
"aggregation of at least some multiple user files". However, the Ulrich reference makes clear 
that the cited "G-node" is neither a user file nor an aggregation of user files: 

"A G-node Table 330 includes a collection of G-nodes, where each G-node contains data 
related to attributes of a file. A one-to-one correspondence exists between the G-nodes and files 
stored on the server node 150." Ulrich, col. 22, lines 9-12. 

Thus, it is clear that the cited G-node contains data related to attributes of a user file but is clearly not a 
user file itself Moreover, a G-node appears to relate to attributes of a single user file and not an 
aggregate of user files. 

The Examiner has cited no portion of the Ulrich reference which in any manner teaches 
or suggests "creating a managed file comprising an aggregation of at least some of the user files" 
as required by claim 1. Independent claims 14, 27, 40, 50, and 53 may be distinguished in a 
similar fashion. 

It is the Examiner's position that the recited "applying first predetermined criteria to a 
user file stored in the retrieval storage pool to designate the user file in the retrieval storage pool 
as one of a higher priority and a lower priority" " of the combined limitations "applying first 
predetermined criteria to a user file stored in the retrieval storage pool to designate the user file 
in the retrieval storage pool as one of a higher priority and a lower priority; and deleting fi-om 
said retrieval storage pool a user file designated as lower priority" of claim 1, is met by a 
description of a checksum comparison operation provided in col. 40, lines 19-44 of the Ulrich 
reference. However, it is respectfully submitted that the Examiner's citation appears to describe 
a process for looking up a "file handle" at the request of a client: 

"FIG. 16 is a flow chart that describes in more detail how the process of the state 1515 
carries out a file handle look-up. The look-up process 1515 begins with a look-up request that 
comprises the file handle 1300 for a directory on the pathname of the desired file and continues 
on through each component of the pathname, retrieving a file handle for each, until a file handle 
for the desired file itself is returned to the client 1 10." Ulrich, col. 39, lines 39-41. 
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It is clear that the checksums are not ordered to assign priorities to individual files but are instead 
ordered to facilitate finding a particular file handle. Still further, it is clear that the checksums 
are not ordered for purposes of determining which user files are to be deleted fi-om a storage pool 
but are instead ordered to facilitate finding a particular file handle. 

It is the Examiner's position that the recited "applying first predetermined criteria to a 
user file stored in the retrieval storage pool to designate the user file in the retrieval storage pool 
as one of a higher priority and a lower priority" of the combined limitations "applying first 
predetermined criteria to a user file stored in the retrieval storage pool to designate the user file 
in the retrieval storage pool as one of a higher priority and a lower priority; and deleting fi-om 
said retrieval storage pool a user file designated as lower priority" of claim 1, is met by a 
description of a file storage operation provided in column 62, lines 20-27 of the Ulrich reference. 
However, it is respectfully submitted that the Examiner's citation appears to describe a process 
for determining how a file is to be stored, not as to whether a file is to be deleted: 

"In one embodiment, the server 130 determines how to store data based on the 
composition of the file and the availability of the different types of parity groups. As shown in 
FIG. 32A, of the different choices for storing File #1, the first parity string 3240 is most efficient 
as it has the lowest total bytes required for storage (5120 bytes total), as well as, a high utilization 
value (100%). Each of the other parity strings 3241-3243 are less desirable for storing the data in 
File #1 due to greater space requirements (larger number of total bytes) and in some cases 
reduced storage efficiency (lower utilization value)." Ulrich, col. 62, lines 17-27. 

It is clear that the parity groups are not considered for purposes of determining which user files 
are to be deleted from a storage pool but are instead evaluated to determine a more optimum 
storage format. 

The Examiner has cited no portion of the Uhich reference which in any maimer teaches 
or suggests "applying first predetermined criteria to a user file stored in the retrieval storage pool 
to designate the user file in the retrieval storage pool as one of a higher priority and a lower 
priority" as required by claim 1. Independent claims 14, 27, 40, 50, and 53 may be distinguished 
in a similar fashion. 



Page 4 of 5 



Pre-Appeal Brief Request for Review Arguments 



Serial No. 10/766,576 
Docket No. SJO920030087US1 
Firm No. 0037.0062 



It is the Examiner's position that the recited "deleting from said retrieval storage pool a 
user file designated as lower priority" of claim 1 is met by the following recitation in the Ulrich 
reference: 

"Furthermore, the one or more Gees corresponding to the logical disk blocks where the 
data from the file is stored are updated to reflect their now occupied status (i.e. removed from 
pool of available or free disk space)." Ulrich, col. 63, lines 59-62. 

The appUcants strongly disagree. The recitation above has no teaching or suggestion of 
deleting a user file. It is respectfully submitted that it relates to the opposite, that is, a description 
of the removal of free space (not the removal of a user file) as a result of the storage (not 
removal) of data. The Examiner has cited no portion of the Ulrich reference which in any 
maimer teaches or suggests "deleting fi-om said retrieval storage pool a user file designated as 
lower priority" wherein the deleted user file was received "from at least one client station 
coupled to a data storage subsystem" as required by claim 1. Independent claims 14, 27, 40, 50, 
and 53 may be distinguished in a similar fashion. 

The rejection of the dependent claims is improper for the reasons given above. 
Moreover, the dependent claims include additional limitations, which in combination with the 
base and intervening claims fi-om which they depend provide still fiirther grounds of patentability 
over the cited art. 

The Examiner has made various comments concerning the anticipation of additional 
features of the present inventions. Applicants respectfully disagree. Applicants have addressed 
those comments directly hereinabove or the Examiner's comments are deemed moot in view of 
the above response. 

Conclusion 

For all the above reasons. Applicants submit that the pending claims 1-54 are patentable 
over the art of record. 



Dated: April 19, 2007 By: /William Konrad/ 

William K. Konrad 
Registration No. 28,868 



Page 5 of 5 



